CAMEL-24505: camel-micrometer-starter - bound the uri metric tag - #1933

Fixes CAMEL-24505.

What

MicrometerTagsAutoConfiguration contributes the uri low cardinality tag of the http.server.requests
metrics. When the request did not resolve to a Camel HTTP consumer — any 404, any request served by something
other than the Camel servlet — the tag was request.getServletPath() + getPathInfo() verbatim.

Micrometer registers one meter per distinct tag value and keeps it for the lifetime of the process, so the
number of meters followed the number of distinct paths clients had requested rather than the number of routes,
and the memory used by the registry grew with the traffic a deployment received. CamelMetricsConfiguration's
own javadoc for uriTagEnabled already states that an unresolved request "will be marked as UNKNOWN", so the
code contradicted the documented behaviour.

Changes

• Requests that do not resolve to a Camel consumer no longer contribute a uri key value. The value computed
  by Spring's own DefaultServerRequestObservationConvention stands instead: the mapped pattern for a Spring
  MVC endpoint, and a constant (UNKNOWN, NOT_FOUND, REDIRECTION) otherwise. This keeps the tag bounded
  and, unlike hard-coding UNKNOWN here, does not throw away the pattern of the Spring MVC and actuator
  endpoints of the same application.
• Requests that do resolve to a Camel consumer are unchanged: the tag is the static consumer path, such as
  /users/{id}.
• camel.metrics.uri-tag-dynamic = true still tags with the requested path (/camel/users/123), which is the
  documented purpose of the option, but only for requests that resolve to a Camel consumer. The consumer is now
  resolved in that mode too, and the value is capped at 200 characters and stripped of control characters so a
  single tag value stays bounded in size.
• The auto-configuration was conditional on camel.metrics.uriTagEnabled. Spring Boot cannot resolve that
  camelCase name from a relaxed binding source, so camel.metrics.uri-tag-enabled = true — the name listed in
  the starter documentation — never enabled the uri tag at all. The condition now uses the kebab-case name;
  both spellings work, since the kebab-case name does resolve through relaxed binding.

Behaviour change

• Applications configured with camel.metrics.uri-tag-enabled = true (kebab-case) now get the Camel uri tag
  where before the auto-configuration silently did not apply.
• The uri tag of requests that are not served by a Camel consumer is the Spring value instead of the raw
  requested path. Dashboards and alerts matching on those raw paths need to use the Spring value.

An upgrade guide entry for the camel-spring-boot section of the Camel 4.23 upgrade guide will be proposed
separately in apache/camel.

Tests

New tests in components-starter/camel-micrometer-starter/src/test (the starter had none), booting the starter
with camel-servlet-starter on a random port and asserting on the http.server.requests meters:

• MicrometerUriTagTest — 10 requests to 10 distinct unmatched paths produce a single meter, and no meter
  carries a requested path; a matched servlet:/users/{id} route yields uri=/users/{id}.
• MicrometerUriTagDynamicTest — same cardinality assertion with uriTagDynamic = true, plus the requested
  path being used for matched requests and a 300 character path being capped. This class configures the
  properties in the legacy camelCase spelling, so both spellings stay covered.

mvn install -pl components-starter/camel-micrometer-starter → Tests run: 5, Failures: 0, Errors: 0.
Both cardinality assertions fail against the previous logic (10 meters for 10 unmatched paths), verified by
running the new tests against it.

The regenerated src/main/docs/micrometer.json and docs/spring-boot/.../starters/micrometer.adoc are
included.

Claude Code (Opus 5) on behalf of Federico Mariani